Waiting Room ーしきい値を決めるときに知っておきたい「だいたい、こんな仕組み」

本記事の内容は 2022.9 時点のブログ記事とドキュメント、FAQを参考に書きましたが、最新の情報は Cloudflare のドキュメントをご確認ください。また、本記事では FIFO （ファーストインファーストアウト）キュー方式を前提に記載しました。

サービスの根本

Waiting room が根本的に実現したかったのは、サーバーを守ること

無理だと感じる、その前に

Waiting Room はいつ発動するのか

アクティブユーザーの合計数

アクティブユーザーの合計数：ベストプラクティスではオリジンの同時処理数の75%で、設定できるのは最低限200以上

オリジンサーバーの同時処理接続数が 1000 であれば 750 となります。

しかし！　「751番目からのユーザーは仮想待機室に送られる」とは限りません。

 

「いつ待機し始めるの？」裏側の仕組み

オリジンサイトに入れるユーザー数をスロット数と呼びます。

{スロット数: オリジンに入れるユーザー数} = {アクティブユーザーの合計数} - {データセンタを通過したユーザー数}

スロット数が 0 （空きがない）に近づいてくると、データセンターはキューイングを開始します。

 

実際は、これを 1 つのデータセンターではなく複数のデータセンターで実現しています。

どうやって？それぞれのデータセンターがスロット数を分け合います。

「東京データセンタ A では 375、大阪データセンタ B でも 375、よろしくね」

基本的に、データセンター A や B は分けてもらった分だけを観察しています。

キューイングを始めるタイミングもデータセンタレベルで独立的に任せられています。

 

もちろん、データセンターで処理したスロット数は裏で集約しています。集約された値が API やダッシュボードに表示されている値です。

 

では、分け合うといってもその割合はどう決めているか？

スロット数を分担する割合を、過去2分間のトラフィック量を基に流動的に調整しています。

（例）2つのデータセンターがあって、最初は 50:50(%) で割り振りました。過去2分間、片方を通るアクセスが多ければ 40:60(%) に変更されるわけです。これを 2 分毎に繰り返します。

 

しきい値は固定値でなく変動値

複数のデータセンターにくるトラフィックの量も、キューを開始するタイミングもバラバラで、割り振られるスロット数も2分毎に変化します。

なので、しきい値といっても結局は目安程度のもので、「751回目」のようにはカウントしきれないのです。

 

アクセスが急増！！

「いつ発動するの？」 「750 **前後**で発動します。」

青グラフはアクセスの増え方が緩やかです。Waiting Room はしきい値 750 よりもたくさんのユーザーをオリジンに受け入れます。

比べて、オレンジグラフはアクセスが急に増えました。Waiting Room は「えらいこっちゃ」ということでしきい値 750 に達していないですが、前もって待機室を発動させます。

どちらも想定内の挙動です。「アクティブユーザーの合計数」はあくまで目安という立ち位置です。

 

分単位の新規ユーザー数

しきい値に関係する項目がもう一つあります。

75%をアクティブユーザーの合計数にしたけれども、もし、一斉にアクセスされてサーバーが耐えられるか心配な時にお使いください。

サーバーの耐久性、サービスの継続性が大事なケースでは、分単位の新規ユーザー数を活用してみてください。

分単位の新規ユーザー数：設定可能な値は、最低 200 以上、アクティブユーザーの合計数以下

 

小さいグループに分けてご案内します

アクティブユーザーの合計数 750 と同じ値を設定すると、最初の1分で 100% のユーザーをオリジンに通します。

比べて、分単位の新規ユーザー数を使うと、小さいグループに分けてオリジンに通すことでサーバー側の急激な負荷を減らすことができます。

{分単位の新規ユーザー数} ÷ {アクティブユーザーの合計数} x 100 = { } %

200 ÷ 750 x 100 = 約 26 %（約は省略）

1分毎に 26 %のユーザーを1グループとみなし、順次オリジンに通します。

 

オリジンに通された後は？

セッション時間

セッションが保たれる時間（分）で、1 分から指定できます。

ユーザーがオリジンに滞在するであろう時間が目安です。

セッション時間は _cfwaitingroom という Cookie の有効期限になります。この Cookie でセッションの有効性を判定しています。

 

シーケンス図

1.. 判定：ループ（毎20秒）

まず、オリジンにアクセスさせるか OR 待機させるかの判定が入ります。この判定は 20 秒毎に繰り返されます。

通過 →→ オリジンサーバーにアクセスさせる。ユーザーはサイトに到達する。

待機 →→ ユーザーの画面には Waiting Room の待機画面を表示させる。予想待ち時間も表示される。20秒毎に判定結果を反映します。画面は自動リロード。

 

2.. 通過（オリジン）

オリジンに到達する最初のセッションで、Cookie に有効期限がつきます。

有効期限はセッション時間(分)で指定した値です。

 

3.. 操作中

HTTP通信があるたび有効期限を更新します。

(例)セッション時間：5 分であれば HTTP 通信があるたびに、5 分間有効な新しい Cookie が払い出されます。

 

4.. セッションが切れたら 1. に戻ります。（並び直し）

セッションが切れるのは、

• 最後の HTTP 通信から {セッション時間} 分後に再アクセスしようとする

• 最後に発行された Cookie の有効期限を過ぎている

• タブやブラウザを閉じる

 

セッションを更新しないこともできる

HTTP 通信毎に更新する前提で図におこしましたが、「HTTP 通信毎に更新しない」こともできます。

その場合は、最初のアクセスから Cookie 有効期限（セッション時間値）が過ぎたら無条件セッションが切れ、最初の判定（1）に戻ります。

 

まとめ

Cloudflare Waiting Room の裏側を一部ご紹介いたしました。

弊社のこちらのブログもあわせてご参考いただけますと幸いです。

• Cloudflare Waiting Roomの設定項目（アクティブユーザーの合計数、分単位の新規ユーザー、セッション時間）についてまとめてみた
• ワクチン予約サイトを落とさない Cloudflare Waiting Room の設定方法

長文読んでいただきありがとうございました！